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Mail Priority 


In RFC 539 (HiC--1764,3a:7y) Postel and I suggested that mail 
Senders ce allcwed to assign a degree Of priority to their mail. 
White (RFC 555--17993,46c:2¥v) odjectea to defining shades of urgency, 
Without having tneir effects upon the mail Protocol server also 
defined. 


If pricrity levels were to pe assigned by automata, I would agree 
With Jim. Unfortunately, the numar sender of the mail will usually 
be tne one to assign the priority, and humans will not be consistent 
in that assisnnert. 


Also unfortunately, the concept of urzency is an integral part of 
communication. If it weren't, We coulda ignore its inclusion into tne 
MP. 


Since distincticns in urgency are useful (necessary?) ana since 
humans will ce the ones aSSigninz specific degrees of urgency 
(thereby making it impossiole for server processes to automatically 
do the "right thing" in response), we suggested oniy including the 
INFORMATION as part of the protocol., Let the human and 
Server-preocess receivers deciae petween tnemselves how the 
Server-process srould aeal with tnat information. 
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Now that I have argued all tnat, let me suggest interpretations for 
urgency values. This is so that programners can have 
automata-cgenerated mail (e.¢., notification of tne status of 
previousiy sent mail) cerry reasonable urgency values: 
10 Phone in the middle of the nizgnt, if necessary. 
9 
8 Deliver to user's terminal NOW. 
7 
6 


Deliver to user's terminal enly if user is at "exec" 
level. i 


Deliver immediately after sign-on or before sign-off. 


Deliver into standard mailbox. 
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